There is one known issue:
For each package the "cppcheck-options:" are printed. But only the options of the last cppcheck run. So currently the options for 1.86 are shown, not for HEAD. Since Boost is only used in HEAD there are no --library=boost options shown in the output currently.
I am not sure if it is worth to fix this for example by saving and showing the "cppcheck-options" for the base AND the HEAD version. Since most of them are most of the time redundant.

Or should we wait with this PR until the next version is released so it is unlikely that the options differ?

Or should we wait with this PR until the next version is released so it is unlikely that the options differ?

Sounds like a good idea

Merge branch 'master' into donate_cpu_use_boost_library

Instead of git merge master in the future, please use git rebase master.

I would recommend a cleanup.

1. goto your branch. git checkout donate_cpu_use_boost_library
2. start a cleanup git rebase master -i
3. An editor will be opened. The commits are shown. Before each commit it says "pick".
4. For all Merge branch 'master'... commits change the "pick" to "squash"
5. Save the changes and exit the editor
6. A new editor will be opened where you write new commit message(s). Not sure exactly how that will look but put a # before each "Merge branch...".
7. Save the changes and exit the editor.

Now the branch should look much better. There should only be your 2 commits.

To push that you will need to use git push -f.

Ok i will try to clean it up.
Does it make any difference when it is squashed and merged in the end?

Does it make any difference when it is squashed and merged in the end?

in the end it does not matter.

Hmm, was that too much "rebase"? Somehow amai is now author of the commit :)

Thanks for the cleanup. I believe you can use git commit --amend --reset-author or something like that to fix the author.

Good idea. I'll try that.

I have commented out the boost include detection and library usage. So this PR can be committed now to avoid rebasing it again and again.

sounds good.

It would be interesting to get a graph about how quick latest Cppcheck is compared to some old Cppcheck versions. I would like to be able to run that sometime. I guess that will require that we leave out various libraries and maybe other flags also.

It would be interesting to get a graph about how quick latest Cppcheck is compared to some old Cppcheck versions. I would like to be able to run that sometime. I guess that will require that we leave out various libraries and maybe other flags also.

The information output is of not much interest in this case too i guess.
Maybe we should add a similar functionality like the one to obtain the version from the server. The client should request options for running Cppcheck, what is sent to the server and so on.
But i am not sure if it makes sense to collect these different data at one server that changes the options from time to time.
IMHO a second server would make sense here. That one could use older versions to compare with and special options to avoid library usage, ...